문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 Go(프로그래밍 언어) (문단 편집) === 장점 === Go 언어의 특징은 컴파일 언어이지만 [[컴파일러]]의 컴파일 속도가 매우 빨라 [[인터프리터]] 언어처럼 쓸 수 있다는 점에 있다.[* 사실 [[C++]]의 컴파일 속도가 복잡한 문법으로 인해 매우 느린 것이다.] 이는 언어의 문법 구조를 개선함으로써 달성하였다. 컴파일러가 소스 코드를 해석하는 pass 수를 줄여서 달성한 것으로 보인다. 접근하기 어렵지 않고, 코드 역시 간결하면서도 컴파일 언어답게 높은 성능을 낼 수 있다는 점이 호평을 받는다. 자료형 체계에 있어 정적 타입(static type) 검사가 이루어지는만큼, [[Python]] 등에 익숙해져 있다가 넘어올 경우 조금 애로사항이 꽃필 수 있다. 간결하게 코드를 작성할 수 있으면서도 풍부한 라이브러리 덕택에 막강한 기능을 쉽게 구현할 수 있다는 것은 큰 장점이다. 그러나 컴파일 언어의 태생적인 한계를 극복한 것은 아니라서 대형 모듈을 이것저것 붙이면 컴파일에 필요한 시간이 있기에 Python 등의 인터프리터 언어보다는 기계어 번역 시 확실히 반응이 느릴 수밖에 없다. 물론 컴파일 언어 중에서는 매우 빠른 편이지만 아무래도 인터프리터 언어의 즉흥성까지 바라는 건 무리. 대신 컴파일 언어인만큼 실행 시 퍼포먼스는 확실하다. 또한 Go는 GoRoutine(이하 고루틴)이라는 비동기 메커니즘을 제공한다. 이 비동기 메커니즘은 [[Erlang]]에서 영향을 받은 것으로 각각의 고루틴은 병렬로 동작하며 메시지 채널을 통해 값을 주고받는다. 고루틴을 사용하면 이벤트 처리, 병렬 프로그래밍 등이 간단해진다. 단, 병렬화된 고루틴의 동기화 문제는 프로그래머가 다뤄야 하며 동기화를 무시할 경우 프로그램이 비정상 종료될 수도 있다. 예를 들어 부모 루틴이 자식 루틴보다 먼저 끝나버리면 자식 루틴은 OS에 의해 메모리에서 강제로 사출되어 버린다. 그래도 동기화 방법은 기존 멀티스레드 응용프로그램에 비해 매우 간단한 편. 단순히 고루틴으로부터 반환값을 받는 코드를 메인 스레드에 추가하면 된다. 고루틴은 멀티스레드 메커니즘이지만 자체적인 스케줄러에 의해 관리되는 경량 스레드이며 OS에서 관리하는 경량 스레드보다 더 경량이다.[* 약 8kbyte] 따라서 고루틴은 CPU 코어수와 무관하게 수백, 수천의 고루틴을 작성해도 성능에 문제가 생기지 않는다. 이는 [[Erlang]]도 마찬가지. Go는 바이너리 컴파일러이므로 서로 다른 머신 플랫폼들을 타겟으로 배포해야 할 경우 환경변수(GOOS와 GOARCH 등)를 그에 맞게 설정한 후 컴파일해서 여러 벌의 배포판을 만들어야 한다. Go는 명시하고 있지 않지만 단순함과 실용성을 지향하는 언어다. keyword가 25개밖에 되지 않고 문법 또한 간결해 입문이 쉬운 편이다. ||break ||default ||func ||interface ||select || ||case ||defer ||go ||map ||struct || ||chan ||else ||goto ||package ||switch || ||const ||fallthrough ||if ||range ||type || ||continue ||for ||import ||return ||var || 보면 알겠지만 [[GOTO]]도 있으며, 예약어로만 존재하고 기능이 없는 [[JAVA]]의 goto와는 달리 실제로 C의 GOTO처럼 사용할 수 있다. 그러나 반쯤 숨겨둔 기능. 컴파일 언어인 덕분에, 속도가 느린 스크립트 언어에서 연산 퍼포먼스가 필요한 부분을 Go로 대체해 넣을 수도 있다. 예를 들면, Go로 만든 코드를 공유 라이브러리로 컴파일해 [[Ruby]]에서 [[FFI]]를 이용해 컴파일한 .so 파일을 가져와 사용하는 식. [[PHP]]에서도 역시 가능하다.[* 그 반대도 가능하다. PHP를 예로 들면, libphp7.so를 이용해 Go에서 PHP 코드를 불러와 실행하는 식이다.] 다만 기본 패키지들은 대개 성능보다는 편의성에 초점을 맞춘 탓에 극한의 성능을 추구하는 경우라면 사용을 권하기 어려운 것들이 있다. 예를 들면 웹 서버 제작시에 쓰이는 net/http나 html/template 등이 그러한데, 이런 경우엔 기본 패키지를 대체하는 별도의 패키지를 이용하면 (실제 체감효과는 별론으로 하되) 벤치마크상으로는 심지어 수십 배나 수치가 좋아지는(...) 경우도 있다.[* 예를 들어 html/template의 경우 성능 저하의 주범으로 여겨지는 reflect를 사용해서 템플릿을 생성할 때 (코드 작성자 입장에서는 할 일이 줄어서 편리하지만) 자동으로 모두 이스케이프 처리를 해서 렌더링을 하므로 속도가 느려지게 된다. 당연하지만 이런 대체 패키지들을 쓰게 되면 대신 코드 작성은 조금 귀찮아지게 되고, 또한 기본 패키지의 문법이 호환되지 않는 경우도 잦다. 다만, 실제 서비스를 구성할 때에는 통상적으로 템플릿 캐싱을 추가할 것이므로 느린 파싱 속도는 사실 문제가 되지 않는다. net/http의 경우에도 [[NGINX]] 못지 않은 성능을 보여주는 대체 패키지인 fasthttp가 존재한다. 이런 물건들을 사용한 몇몇 프레임워크들은 유독 벤치마크 그래프가 하늘을 뚫을 기세로 눈에 띈다.(...) 다만, [[HTTP/2]]를 지원하지 못한다거나 하는 식으로 다 일장일단이 있으니 용도에 맞게 찾아보는 것이 좋다.]저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기